STraTOS 1997 April & May

home *** CD-ROM | disk | FTP | other *** search

/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / LITTLE / TOOLKIT.ZIP / DOCS / 68040CFG.TXT next >

Wrap

Text File | 1997-01-22 | 25.8 KB | 572 lines

*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* MC68040 configuration tool - copyright 1996 Douglas Little *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This program (68040CFG.PRG) can be used to modify the driver module to achieve the exact configuration you want. Using this tool is very easy, but it contains some very complicated options which require detailed explanation. Make sure you know what something does before you change it! *-----------------------------------------------------------------------* Getting started *-----------------------------------------------------------------------* * Configuring the driver program. To alter the configuration of the driver program simply drag-and-drop it onto the configuration tool: 68040DRV.PRG -> 68040CFG.APP You will then be presented with a strange looking desktop sporting a large 68040 processor logo/graphic and a bunch of dialog boxes. The dialogs can be dragged around by their 'grip' bars, and they can also be 'topped' with a sharp single-click to these same bars. The configuration currently held in the driver will be shown in the form of depressed buttons on the dialogs. In other words, you are looking at the CURRENT configuration of the DRIVER - not at default values built into 68040CFG.APP. *-----------------------------------------------------------------------* SETUP dialog ------------ * Loading configuration files. Sort through the dialogs until you find the one marked 'SETUP'. Click on the 'LOAD CONFIG FILE' button and select one of the *.040 config files from the CONFIG.040 folder. The new settings should now be visible on the dialog boxes in the form of a different set of depressed buttons. * Saving configuration files. Once you have a satisfactory setup, and you wish to keep it for later use, simply hit the 'SAVE CONFIG FILE' button on the 'SETUP' dialog. The file extension for the output configuration is '*.040', which should prevent them getting mixed up with other unrelated CFG files. * Transferring configurations into the 68040 driver program. If you are happy with your setup, and want to write these changes into the 68040DRV.PRG driver file, simply hit the 'SAVE INTO DRIVER' button on the 'SETUP' dialog. The driver is now configured for use! *-----------------------------------------------------------------------* Advanced options *-----------------------------------------------------------------------* RAM dialog ---------- * 32-bit FastRAM This option enables any 32-bit local memory detected between addresses $01000000 and $04FFFFFF (64MB in total). Even if the ram is not found to be one long contiguous block, it will be 'defragmented' and placed at address $01000000 (16MB) using the 68040's on-chip 'Programmable Memory Management Unit' (68040 PMMU). Any FastRAM required for other purposes such as FastROM or 'fast system pages $8000->$9FFF' will be subtracted from the FastRAM pool before being made available to the system via this option. * Cacheable RAM Turning on this option allows any FastRAM located by the driver to be cacheable via the CPU's (twin) on-chip 4Kb caches (8Kb in total). It is advisable to keep this enabled purely for speed, but it may be useful be able to turn it off for compatibility reasons with some very badly behaved software. It only affects FastRAM, and does not interfere with the cacheing of normal 'ST' RAM. See the section on 'MASKS' for information on setting up non-cacheable ST RAM screen memory. * FastRAM check This feature simply performs an adaptive read-write-read scan of all remaining (system) FastRAM detected by the driver. It only checks available FastRAM, which means enabling the FastROM or 'fast system pages' options (described elsewhere) will reduce the length of the check very slightly. This is quite normal. *-----------------------------------------------------------------------* ROM dialog ---------- * 32-bit FastROM Enabling this option causes the Falcon's ROM to be transferred into FastRAM (if it is available) at the relatively small expense of around 512kb of real memory. All remaining FastRAM is located at address $01000000, as you would normally expect for TT compatibility. The ROM image is patched for 68040 compatibility AUTOMATICALLY when it is transferred to FastRAM. This means extra speed, and makes the machine more reliable to use. A brief list of the current ROM patches are described elsewhere in this package. DO NOT use this feature with replacement operating systems like MagiC. This could lead to quite serious problems which are often difficult to describe. * Cacheable ROM This is exactly the same as the cacheable RAM option described above, except it applies to the ROM. It affects the cacheing of ROM regardless of what or where it is - FastROM enabled or otherwise. It may be useful for debugging purposes when attempting to produce customised ROM images or creating ROM patches like WINX. Aside from this, it is of little real value and this button should be left enabled at all times. * Simulate GEMRAM Specially for users of the WINX GEM-patch. This simply tricks WINX into thinking GEMRAM is installed, and so allows WINX to be loaded into FastRAM, and hook into the ROM image held there. Kills two birds with one stone, as the saying goes. If you don't have FastRAM, you would probably be better off using GEMRAM instead for loading WINX, as it has other features (like environment string setup) which are not covered here (yet). * I-Cache on reset This option only works when both the '32-Bit FastROM' and 'Resurrect PMMU' options are enabled simultaneously. If either of these options are left unselected, nothing will happen. It patches TOS 4.04 in FastROM to enable the instruction cache immediately on a warm reset, which can speed up booting times. This can depend on your hard-disk driver software, as it may simply disable the cache first chance it gets. Generally though, it does make an appriciable difference. * Nemesis on reset This option only works when both the '32-Bit FastROM' and 'Resurrect PMMU' options are enabled simultaneously. If either of these options are left unselected, nothing will happen. It patches TOS 4.04 in FastROM to enable the 20MHz bus mode of the Nemesis accelerator immediately on a warm reset. This tends to speed up boot times by as much as 25%, and is worth using if you have Nemesis installed. You may need to alter your Nemesis installation very slightly to get this working, but the alteration is small. * Writeprotect ROM This simply write-protects the FastROM image after patching. If this option is used, WINX will be unable to hook into the image and will bomb in the auto folder. It does however ensure nothing else corrupts the TOS code, and can be useful for locating dodgey software. * Bootstrap Loader This option forces the driver to perform a warm reset after setting up the MMU tree and FastRAM and patching the FastROM TOS image. This warm reset is only performed once, and does not happen when the driver runs for the second time. This is similar to the way Magic installs itself initially. The purpose of this option is to ensure the initial bootup conditions are identical in every way to all future warm boots after installation. If this option is not used with FastROM & Resurrect PMMU enabled, then the first (cold) boot will be from an unpatched ROM, which may lead to inconsistencies when the machine is reset and then boots from a properly patched ROM. This is not harmful, but can be confusing. For this reason, it is advised that FastROM be used with _BOTH_ 'Resurrect PMMU' and 'Bootstrap loader' enabled! *-----------------------------------------------------------------------* PATCH dialog ------------ * Sector READ/WRITE This buttons allows the user to enable/disable the entire 'Disk patches' dialog in one go. It also prevents the installation of the HDV_? vectors themselves, which may be necessary with VERY sensitive or flaky software. Bear in mind that nothing on the 'Disk patches' dialog will have any effect unless this button is enabled. * Use HDV_? vectors Using this button will prevent the driver from hooking into the trap #13 operating system vectors in order to patch the sector read/write calls responsible for the features on the DISK PATCHES dialog. The HDV_??? harddisk vectors are used instead, which will increase compatibility with some programs, but is at greater risk of being stamped out by other harddisk software. If you run your harddisk driver AFTER the 68040 driver, the HDV_??? vectors will be replaced - killing all of the patches. If this is the case, then you should stick with the usual trap #13 patching method by leaving this button disabled. * MetaDOS functions If you use MetaDOS with a SCSI CD-Rom (or equivalent SCSI device) then you may need to enable this option, which freezes the data cache around MetaDOS calls $30-$3F. This was discovered by Geir Oeyvind Vaelida, who suffered from CD-Rom transfer errors before a version of this patch was developed. A modified version of his patch has been incorporated into the ToolKit driver to keep the AUTO folder size to a minimum. If you use MetaDOS with an IDE CD-ROM drive, then you will probably not require this feature at all, since it only affects SCSI. * VDI blitter patch Unfortunately, TOS 4.04 expects to be able to use the blitter hardware at any time it wants, even if it is supposed to be turned off. When coupled with the fact that the blitter cannot 'reach' FastRAM and will often end up trashing ST-RAM in the attempt, it is beneficial to 'bypass' the blitter in some way when it is trying to copy memory from one place to another. Line, box and fill operations are not so much of a problem, as these are normally performed directly to the screen, but rastercopies are less predictable and must be intercepted in software. This feature installs a VDI patch which intercepts rastercopy operations to ensure the blitter does not access FastRAM directly. The patch is not perfect, but it works under most conditions. It is however advised that the user sticks with NVDI which removes this problem entirely and also contributes substantially to the screen performance. For those users without NVDI, or who cannot use it for some technical reason, the VDI patch should prove very useful. It is however completely pointless if FastRAM is not available. *-----------------------------------------------------------------------* 68040 dialog ------------ * Enable I-Cache Turning this option on will enable the 68040's instruction cache as soon as the driver is finished loading from the auto folder. This means that everything FOLLOWING the driver will be executed with the cache active - and this will continue until the desktop is reached where it will remain on until it is disabled via the supplied cache utilities or the CPX. This option should normally be left on, since it doesn't generally interfere with very much, and it does contribute greatly to the speed of the system. * Enable D-Cache This is identical to the 'Enable I-Cache' button, except it enables the 68040's on-chip data cache instead. This cache is a little more troublesome than the instruction cache, and so there may be some situations where you will want this left off until a later stage in the auto folder. A good example is where you might be running HDDriver from the auto folder, after the 68040 driver. HDDriver can't log SCSI drives with the data cache enabled, so it must be left off until after HDDriver has logged all SCSI devices. The supplied BCACHE40.PRG utility can be used to enable the both caches from the auto folder, just after HDDriver has finished loading. Note: Not all disk drivers behave in exactly the same way - you may need to experiment to get things 100% reliable. See the 'Disk patches' dialog for more information on improving disk driver compatibility. * Resurrect PMMU This one is rather complicated to explain, but is very powerful when it is used properly with some of the other options. There are currently two possible configuration, with two slightly different purposes: 1) Loading Magic into FastRAM, and making it reset-resident. This option should be used _WITHOUT_ the '32-bit FastROM' and _WITHOUT_ the 'Bootstrap Loader' options enabled, if you wish to allow Magic to be loaded into FastRAM. Details are given elsewhere on setting up your auto folder and program flags to get this to work. 2) Patching TOS 4.04 as reset-resident FastROM. (new feature) Using the 'Resurrect PMMU' option _WITH_ '32-bit FastROM' enabled ('Bootstrap Loader' is optional), you can force the TOS ROM to install itself as reset-resident in FastRAM just like Magic does. See details on 'Bootstrap Loader' for more information. What it does is set up the 68040's programmable MMU so that it can be successfully 'raised from the dead' after a warm reset. This means FastRAM, FastROM, copyback and anything else dictated by the 68040's PMMU will be available immediately from boot time. Don't enable this unless you are trying to run MagiC or TOS 4.04 from FastRAM, otherwise you will end up with strange problems that are well beyond the scope of this document. Enough said! * $8000-$9FFF CBC (system pages = copyback cache mode) If you use lots of mathematically-intensive programs like raytracers, renderers or CAD programs, this feature will greatly enhance the 68040 FPU's number-crunching throughput. Values in excess of 400% standard expected performance can be realised this way. Other areas related to exception processing and internal TOS functions are also accelerated, but to a lesser degree. Only the full 68040 processor implementation (integral FPU) will be substantially affected by this particular option when applied for the sake of mathematical work, but FULL copyback support may be accessed via the ECBACK40.PRG utility supplied with this package. See elsewhere for details on how to use this safely. This feature relies on the fact that TOS has reserved very low areas of RAM (in this case, page areas $8000-$9FFF) for special exception stacks and temporary buffers. It also relies on a large number of rapidly successive exceptions taking place over a sustained period - which is exactly what happens during 68882 emulation via the 68882 driver software. Native 68040 binaries will probably not benefit so much - but will be faster than emulation in any case. Native 68040 binaries are very rare on the Atari platform, so you are unlikely to have any around in order to test my theory (yet). Note: This feature is experimental at the moment, and should be used with some care. It basically allows the 68040 to retain data inside it's caches without bothering to write it back to main memory until it feels like it. This is very similar to the delayed-write caches which are common on hard-drives. Since TOS was never written to support this sneaky technology, it could lead to similar problems where data in RAM could be 'lost' from time to time because the cache doesn't get flushed properly before it gets cleared or disabled. I'm not saying this WILL happen, only that I am unable to assure you that it CAN'T happen! The 68040 driver goes to fantastic lengths to ensure data does not get 'lost' when copyback mode is enabled, but there is no ASSURANCE that the ROM kernel or some other software will not trash the cache for some reason - and lead to some inexplicable crash or lockup. This kind of problem is essentially impossible during disk access, since the disk calls have been very well surrounded with re-entrant cache-flushing routines. The problem (if there is one) will be down to the ROM/OS or third-party software fiddling with the cache registers during certain operations. There is no real likelihood that copyback mode will lead to loss of data from harddisk. The problem is almost completely CPU-related. If in doubt, leave this feature off. I do however find it very useful and leave it on all of the time. That's as much of an endorsement as you are going to get out of me on this one. Try it yourself and see what YOU think. :) * $8000-$9FFF FAST (system pages = FastRAM) This option is almost identical to the one described above, except for the fact that instead of depending on the copyback cache for acceleration, it transfers pages of FastRAM down from the FastRAM pool to replace the standard ST-RAM system pages. The performance increase is generally not as great as using copyback mode, but the trick is you can use them both at once. Anything that can't take advantage of copyback mode properly will be accelerated by faster read/write times! Again, this feature is experimental - and there is a chance that harddisk drivers or other programs which use DMA will (for some as-yet unexplained reason) access these pages directly, resulting in serious problems. These pages cannot be fastram-buffered in the same way as normal FastRAM, but they are normally too far out of reach for this to be a problem. *-----------------------------------------------------------------------* MASKS dialog ------------ * Videl Display (4MB) By turning this option on, you can mark the entire last megabyte in ST-RAM on a 4MB Falcon as non-cacheable. Strange as it may sound, this actually speeds up screen redraws in most cases. Since the last 1MB is usually where the Videl screen display is held, and since most screen activity is performed using 16-bit reads/writes or large block copies, the data cache usually ends up getting trashed constantly during redraws when it could be doing something far more useful like keeping records of tables, stacked variables or even just small graphics like fonts, fills or icons. The reason 16-bit reads and writes are particularly bad is because they tend to invalidate large quantities of 'good' data already in the cache, without actually being cached themselves. Only aligned 32-bit reads & writes can be expected to cache effectively. Result: Small, but significant, performance increase during screen redraws under most operating systems. * Videl Display (14MB) Exactly the same as the option described above, except this one is for 14MB Falcons. I could have made it autodetect, but I thought some people might want to experiment with either option - if they have 14MB machines. * NOVA I/O INTERFACE This button should be enabled if you are attempting to use a 2MB Nova or SuperNova video card on your 68040-based Falcon. If you use a Nova card, and you DON'T enable this option, then all access to the Nova's hardware registers will end up being cached, and will confuse both the Falcon and the Nova. * NOVA COLOUR DISPLAY This allows you to mask the Nova card's colour display area as 'non- serialized', which allows the 68040 to write data to the card in any order it wants, as opposed to the exact sequence requested. This seems to make a small, but noticable difference to performance. * NOVA MONO DISPLAY Same as above, but for 2-colour modes - which the Nova card maps to a completely different location in memory. *-----------------------------------------------------------------------* DISK PATCHES dialog ------------------- * Buffer Internally This option is very important for anyone using FastRAM. It allows data passing to and from DMA-based devices such as Floppy disks or SCSI drives to be buffered via ST-RAM. This prevents loss of data due to the OS attempting to perform DMA transfers through FastRAM - which is technically impossible and causes read/write errors. Use this option if you are using FastRAM with Floppy disk or SCSI devices - in fact, anything using DMA for that matter. All drives marked 'DMA/FRB' using the drive letter buttons will be buffered in this way - so make sure you have set them up correctly! Internal buffering may be faster than using the XFRB system, since you can specify which drives to exclude from the process (usually IDE devices), and the buffering routines use 68040-specific code for speed. This may be a consideration when choosing which system to use under MagiC, or any other similar OS. In some extreme cases, it may be safer to enable both options, in case an attempt is made by very low-level programs to bypass the 68040 driver disk patches. It should be noted that this is an unlikely prospect, and is shown here only as a warning. * Enforce buffering Normally the driver is intelligent enough to make decisions about when and where DMA buffering is necessary. It can skip buffering if it decides a disk transfer is not taking place to or from FastRAM. Under very extreme circumstances (i.e. somebody messing about with the 68040 MMU) it is possible that the location of FastRAM could be changed, and this will confuse the driver's decision making process. If this is happening, then you can enable this option to turn off the decision logic - forcing all DMA devices to be buffered at all times - even when the transfer appears to be taking place in ST-RAM. Drive letter buttons -------------------- * DMA/FRB This row of buttons allows you to choose which drives use DMA hardware to transfer data. This includes all Floppy disk and SCSI devices, or anything at all that connects to the SCSI port and appears as a disk drive to the Falcon. These buttons are used to indicate two things to the driver: 1) Any drives flagged using these buttons are assumed to be 'volatile' because the DMA hardware does not communicate with the CPU caches and requires them to be 'flushed' before and after every read/write operation. If you are getting disk errors, or are finding that your data is becoming unreliable, then make sure all DMA drives have this button enabled. It could be caused by 'stale' data in the caches. 2) If the 'Buffer Internally' button is ALSO used, then all drives flagged using these buttons will be buffered via ST-RAM. Any devices not flagged with these buttons will be ignored by the driver's internal buffering system. * I-Cache TOS is so 68040-unfriendly that most harddisk drivers can't access the disk while the CPU caches are enabled at all. If you are using SCSI devices (or even floppy disk!), and you don't want to suffer turning the caches off completely, you can use these buttons to 'mark' which drives are at risk - allowing the driver to 'freeze' the caches around disk reads and writes to those drives. This row of buttons allows you to mark drives which cannot be written or read when the INSTRUCTION cache is active. Enabling one of these buttons causes the cache to be locked OFF during access to that drive, being re-enabled after the disk activity has finished. VERY few disk drivers should have problems with the instruction cache, but the feature is available for those situations if and when they arise. Generally, this row should be ignored for all but the most troublesome harddisk drivers. You can normally ignore this button for floppy disk drives as well. * D-Cache This row of buttons allows you to mark drives which cannot be written or read when the DATA cache is active. Enabling one of these buttons causes the cache to be locked OFF during access to that drive, being re-enabled after the disk activity has finished. Most harddisk drivers have problems with the data cache, since DMA transfers tend to be transparent to the CPU, leaving potentially stale data inside the cache which can then return to the system soon after the disk transfer is complete. Although the caches are flushed around all read/write operations performed on drives flagged as 'DMA/FRB', the caches start re-filling with data almost immediately. This can be a very serious problem when the disk driver is mucking around with the data before or after the transfer happens. It will PROBABLY be necessary to enable one button in this row, for every DMA device you have attatched - just like you (hopefully) did with the DMA/FRB buttons described above, unless you are ABSOLUTELY CERTAIN your setup does not require it. If you do not use any of these buttons, then can I at least suggest that you keep one eye on this situation at all times. It's not worth loosing data for a meagre 0.1% harddisk speed increase! You can usually find out how well your disk driver behaves by running disk tests using Diamond Edge or Correct, or some other integrity checker without risking loss of data, so long as you make sure any 'auto-fix errors' options are disabled. However, these programs do not ALWAYS pick problems up - especially problems with the data cache and SCSI drives. Sometimes the only way to detect these faults is to read/write lots of data to an empty SCSI partition and just see what happens... And please, DON'T try to optimise any of your drives until you are sure your driver is properly set up! *-----------------------------------------------------------------------*